TeX 1995 July/TeX CD-ROM July 1995 (Disc 1)(Walnut Creek)(1995).ISO/dviware/beebe/updates/00mail.16

Text File | 1990-10-01 | 26KB | 655 lines

26-May-88 18:15:50-MDT,26245;000000000001
Date: Thu 26 May 88 18:15:48-MDT
From: "Nelson H.F. Beebe" <[e-mail]>
Subject: DVI driver family update #16
To: "DVI mailing list part 2": ;
cc: [e-mail]
X-US-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112"
X-Telephone: [phone]
Message-ID: <[e-mail]>

                  DVI Driver Family Update #16
                           [26-May-88]


============
INTRODUCTION
============

This newsletter should have gone out a couple of months ago,
but I have just been too busy.  Utah is in the process of
planning for the purchase of a supercomputer, and I've been
serving on the technical committee for it since Oct-87.
Bids have now come in, and evaluations are underway.

I will be away from Salt Lake from 9-June to 5-August, and
unfortunately, will not be able to get Version 2.11 released
before I leave.  I therefore felt that this issue had better
get out now, or you won't hear from me until September.
With my current mail volume, I expect that it will take 3 to
4 weeks after my return just to open and answer mail,
sigh...


============
MAKE PROGRAM
============
 One of the notes below comments on a bug in the
public-domain version of Make.  Ignore the comment about
volunteer efforts for preparing a fix.  Since Easter, I've
developed a brand new ground-up reimplementation of Make
which on completion of testing will be available on the same
terms as the DVI family.  This new implementation is
designed from the start to eliminate all the misfeatures of
other Makes, add features of newer Unix Makes, plus
directives similar to those of the C preprocessor (but with
! instead of # prefixes), conform completely to January 1988
draft ANSI C, run on multiple operating systems, and conform
(mostly) to the syntax of Unix Make.  It is being tested
locally on a dozen different machines representing 5
hardware architectures and 4 operating systems.  I'd hoped
to have it ready for beta testing before my June departure,
but alas, that will not be possible either.  The current
version is working locally, has about 8800 lines of code in
itself and support software, plus about 100 pages of
documentation in two manuals.  If any of you are interested
in getting your name in for a beta test release, send me
mail to that effect; it will, however, require that you have
Internet access for FTP, because I will not send tapes or
floppies, and it is too big for easy electronic mail
distribution.


=======
TURBO C
=======

Several people tried (unsuccessfully) to implement the
driver family on the IBM PC with Turbo C 1.0.  The large
number of bugs that were being reported on the net
discouraged me from even buying it (one of the bugs resulted
in the reciprocal of division results being returned).  I
bought version 1.5, and made some extensive tests with it on
the DVI family, the ELEFUNT elementary function test
package, and on my new Make implementation.

The good news is that Turbo C 1.5 is fast; compilation of
one DVI driver on the PC XT drops from 35 minutes with
Microsoft C 5.0 to 7 minutes with Turbo C 1.5.

The bad news is that the compiler is fatally flawed for C
programs containing floating-point, to the extent that even
random numeric constants are compiled into incorrect values!
I won't go into further details about this.  A 10-page
letter to Borland International resulted in a positive
response from the software development director, and my
appointment as a beta test site for 2.0, which in-house at
least, fixes all the bugs I reported.

Given that the discounted price of Microsoft C is about
$350, and that of Turbo C about $45, it would be nice to
switch to Turbo C.  For the new Make, which has no
floating-point usage, Turbo C performs admirably, and I've
not detected any bugs that affect Make.

The Turbo C library is not as complete as the Microsoft C
library; it lacks the <sys/xxx.h> files, <signal.h> and
signal(), utime(), and probably some others.  The output
.EXE files seem to be somewhat smaller than those from
Microsoft C 5.0, and TLINK is much faster than LINK.  LINK
can also be used with Turbo C output.  Although Turbo C does
support most draft ANSI C syntax, it does not issue as many
helpful diagnostics as Microsoft C does, nor does it have an
option to produce ANSI style declarations from existing
code.  Also, Turbo C's command line options are not
standard; instead of "cc -o foo foo.c", you have to write
"tcc -efoo foo.c" (no space after -e), which requires
additional nuisance changes in Makefiles.

Wildcard command-line expansion for compiled programs is
automatic; with Microsoft C, a special library routine has
to be loaded.


=====================
LATEX EDITING SUPPORT
=====================

I have developed some extensive support for editing LaTeX
files in GNU Emacs, which is widely available and runs on
most Unix and VMS systems.  We are shipping Emacs copies on
VMS BACKUP tapes with the DVI drivers.  The latex.el library
is now at beta test release 0.07, with 34 sites
participating.

latex.el grew out of a translation from TECO to Lisp of the
editing support I developed for TOPS-20 Emacs, which is
described in our Local LaTeX Guide; many of you have seen it
(it is accessible for ANONYMOUS FTP from SCIENCE.UTAH.EDU in
APS:<TEX.PUB.LOCAL-GUIDE>.  Thanks to the ease of
programming in Lisp, I have added many new features,
including the availability on a key of every macro in the
LaTeX book, together with helpful information about macro
arguments.  There is also support for SliTeX.  The current
development version (pre-0.08) of latex.el is 2513 lines
long.

The library has a LaTeX-gripe function that makes it easy
for users to mail comments to me while they are still in the
editor , and I have several submissions that contain good
ideas that I'd like to implement before the final release.

I'd hoped to finish up the test before my departure, and
make an official release of latex.el to the Free Software
Foundation, but again, this will not be possible until at
least August.


===========
MAKEINDEX
===========

One of the changes recorded below is a correction to
TeXindex.  After uncovering some further misfeatures of
TeXindex that make it unable on the IBM PC to handle index
files larger than 32767 bytes long (that in itself is a long
story), I turned my efforts to seeing if MakeIndex could be
gotten to work on non-Unix environments.  That indeed was
the case, after a fair amount of work, and a couple of
months ago, an announcement of it was made on TeXhax.
MakeIndex now runs on all the systems that the DVI driver
family runs under (except IBM VM/CMS), and is a much
superior system.  There was initial confusion about its
release status, because it was developed at the Berkeley
VORTeX project, which licenses its software for a fee.  That
has been worked out, and MakeIndex may be freely
distributed; if that had not happened, I would have turned
elsewhere in search of a public indexing system.  Pehong
Chen and Leslie Lamport have done an excellent job of
MakeIndex, and I urge you to get it and adopt it.  Copies
are available for ANONYMOUS FTP from UCBVAX.BERKELEY.EDU,
SCIENCE.UTAH.EDU, CTRSCI.UTAH.EDU, and
JUNE.CS.WASHINGTON.EDU.  It will become part of the
Washington Unix TeX distribution, and is also included on
DVI tapes that we ship from Utah.


=======================
DVI DRIVER DEVELOPMENTS
=======================

Since the 2.10 release in November, 1987, the DVI family has
seen the addition of two new drivers, DVIADX, for the Anadex
Silent Scribe 72dpi and 144 dpi dot matrix printers and
DVIGP, for the Phillips GP 72dpi and 144dpi dot matrix
printers.  With these two, I am discontinuing the practice
of maintaining separate programs for different resolutions
of the same device (as was done for the Apple Imagewriter,
Okidata, and Epson printers); local recompilation with
different compile-time switch values can produce programs to
support the two resolutions.

A significant new development during the past month has been
the first successful port of the family to IBM VM/CMS using
the Waterloo C compiler; the changes have been merged into
my development sources, and will be available when 2.11
comes out.  Shashi Sathaye at the University of Kentucky
gets credit for this; I've sent her a copy of the current
sources for verification of the merged changes.  A couple of
weeks after I received her changes, I got notification from
Russell Fulton at the University of Auckland in New Zealand
that the start of a port to VM/CMS had also been made there.
Previous attempts elsewhere with the SAS and IBM C compilers
have been stymied by compiler bugs.

I've also received from Julian Perry an update for 2.10 of
the changes to dvijep.c to support portrait and landscape
printing, and Steven H. Gutfreund has supplied modifications
to support \special{}.  Neither of these are currently
merged into the master sources, because I'm awaiting the
completion of the TeX Users Group committee report on
standardization of \special{}s and other DVI driver
features.  On request, I have mailed the changes to
individuals who wanted to merge them into their own private
versions of dvijep.

Thanks to the good efforts of the following people:

"[e-mail]":
! The DVICAN mailing list [25-May-88] !
[e-mail],                !Nelson H.F. Beebe!
[e-mail],    !Yves Bertheau!
[e-mail],        !David Terrett!
[e-mail], !Gerd Friesland!
[e-mail],        !Richard J.J. Tobias!
[e-mail],        !Pekka Pietilainen!
[e-mail]                ! !
!**** Last Line ****

dvican, the driver for the Canon LBP 8 A2, has been
substantially improved.  I've formed a small mailing list
(the above people) to exchange correspondence about it; if
any of you on this larger DVI list (currently 224 sites)
have a Canon A2, let me know (soon), so I can get you on the
small list too.


==============
CHANGE HISTORY
==============

Because of the work noted in the preceding section, the
development directories have many more changes than are
recorded here.  These here are ones that you might want to
patch into your local sources if they appear to impact you;
if not, just sit tight and wait for 2.11.

[18-May-88]
                In dvijep.c about line 180, change
        {PUTESC; sprintf(plotfs,"*c%dE",MAP_CHAR(ch)); OUTST(plotfs); }\
                to
        {PUTESC; sprintf(plotfs,"*cd%dE",MAP_CHAR(ch)); OUTST(plotfs); }\
                This correction sets  the font number  to 0;  the
                old one works on the HP LaserJet, but might break
                on clones.

[14-Apr-88]
                Changed system() in vaxvms.c to allow warning and
                information  status  returns  to  be  treated  as
                success.  The body of system() now reads:

        t.dsc$w_length = strlen(s);
        t.dsc$a_pointer = s;
        t.dsc$b_class = DSC$K_CLASS_S;
        t.dsc$b_dtype = DSC$K_DTYPE_T;

        /* The 3 low-order bits of stat are
                0 (warning),
                1 (success),
                2 (error),
                3 (information), or
                4 (severe or fatal error)
           Consider values of 0, 1, or 3 to be success.  LIB$SPAWN
           will usually return SS$_NORMAL, independent of the value
           of stat.
        */

        if (LIB$SPAWN(&t,0,0,0,0,0,&stat) != SS$_NORMAL)
            return (127);
        switch (stat & 7)
        {
        case 0:
        case 1:
        case 3:
            return (0);
        default:
            return (127);
        }


[07-Mar-88]
                Changed type of main()  in keytst.c and  lptops.c
                from void to int,  and inserted return(0) at  end
                to keep lint and VAX VMS C compiler happy.  Draft
                ANSI C (Oct-86 and Jan-88) does not specify  what
                the type of main() should be, and most  compilers
                don't  care.   VMS  C  2.3  however  produces  an
                annoying warning message if main() is not of type
                int; I view this  behavior as erroneous,  because
                main() is  only  a convention  in  C, and  it  is
                possible   to   write   C   programs   in    many
                implementations that do not have a main().

[02-Mar-88]
                Added code to findpost.h to ignore trailing  NULs
                in a .DVI file, borrowing code from readpxl.h and
                readgf.h that do the  same thing for font  files.
                Users (including  me) have  been annoyed  by  the
                inability of the  drivers to handle  a .DVI  file
                which has passed through  a VAX VMS system  where
                gratuitous NULs  are  appended to  pad  the  file
                length to a multiple of 512 bytes.

                This effort  revealed another  problem under  VAX
                VMS, and  that is  that the  code in  FSEEK()  in
                vaxvms.c on a request to position at  end-of-file
                actually positions  before  the  last  character,
                instead of after  it.  An  attempt at  correcting
                this was foiled by the VMS library ftell()  which
                returns 0  when the  position set  by FSEEK()  is
                outside the actual file limits, and while FTELL()
                can correct the  brain-damaged value returned  by
                ftell(), it  cannot distinguish  a nonsensical  0
                result from ftell()  at end-of-file  from one  at
                the beginning of the file.  Consequently, it  has
                been  necessary   in  findpost.h   to  bump   the
                postambleptr value by one.

                Since  this   modification   can   be   installed
                independently in  even old  versions of  the  DVI
                driver family, and  a context difference  listing
                is larger than findpost.h,  here is the  complete
                new version:

/* -*-C-*- findpost.h */
/*-->findpost*/
/**********************************************************************/
/****************************** findpost ******************************/
/**********************************************************************/

void
findpost()

{
    register long       postambleptr;
    register BYTE       i;
    register UNSIGN16 the_char;         /* loop index */

    (void) FSEEK (dvifp, 0L, 2);        /* goto end of file */

    /* VAX VMS binary files are stored with NUL padding to the next
    512 byte multiple.  We therefore search backwards to the last
    non-NULL byte to find the real end-of-file, then move back from
    that.  Even if we are not on a VAX VMS system, the DVI file might
    have passed through one on its way to the current host, so we
    ignore trailing NULs on all machines. */

    while (FSEEK(dvifp,-1L,1) == 0)
    {
        the_char = (UNSIGN16)fgetc(dvifp);
        if (the_char)
          break;                /* exit leaving pointer PAST last non-NUL */
        UNGETC((char)the_char,dvifp);
    }

    postambleptr = FTELL(dvifp) - 4;

#if    OS_VAXVMS
    /* There is a problem with FSEEK() that I cannot fix just now.  A
    request to position to end-of-file cannot be made to work correctly,
    so FSEEK() positions in front of the last byte, instead of past it.
    We therefore modify postambleptr accordingly to account for this. */

    postambleptr++;
#endif

    (void) FSEEK (dvifp, postambleptr, 0);
    while (TRUE)
    {
        (void) FSEEK (dvifp, --(postambleptr), 0);
        if (((i = (BYTE)nosignex(dvifp,(BYTE)1)) != 223) &&
            (i != DVIFORMAT))
            (void)fatal("findpost():  Bad end of DVI file");
        if (i == DVIFORMAT)
            break;
    }
    (void) FSEEK (dvifp, postambleptr - 4, 0);
    (void) FSEEK (dvifp, (long)nosignex(dvifp,(BYTE)4), 0);
}

[20-Feb-88]
                We have  uncovered  a bug  in  the  public-domain
                multi-operating-system  make   utility,   pdmake.
                When a file  in a dependent  list must itself  be
                built by  application of a rule, the  value of $<
                gets changed  to reflect  that new  file, but  is
                subsequently not restored  to its  value for  the
                original target file.  Make  will then apply  the
                rule for the target file, but use the wrong  file
                name.   This  situation  never  occurred  before,
                because dependent files are usually just  include
                files,  which   never  have   to  be   built   by
                application of a rule.  The workaround in such  a
                case is  to  replace  use  of $<  in  a  rule  by
                $*.suffix.

                Here is a  simple makefile  that illustrates  the
                bug:

DEBUG  = /NOTRACE /NODEBUG
BFLAGS = /NOLIST $(DEBUG)

.SUFFIXES: .obj .l32 .b32 .r32

.b32.obj:
        echo
        echo '.B32.OBJ:'
        echo '$$@' = [$@]
        echo '$$*' = [$*]
        echo '$$<' = [$<]
        echo '$$?' = [$?]
        bliss $(BFLAGS) /OBJECT=$*.obj $<

.r32.l32:
        echo
        echo '.R32.L32:'
        echo '$$@' = [$@]
        echo '$$*' = [$*]
        echo '$$<' = [$<]
        echo '$$?' = [$?]
        bliss /library=$*.l32 $<

ftp_user.obj: ftp.l32 cli.l32

                To  try  it,  create  3  empty  files:   cli.r32,
                ftp.r32, and  ftp_user.b32, and  then type  "make
                -n".  Unix make will correctly say

                echo '$<' = [ftp_user.b32]

                while pdmake will incorrectly say

                echo '$<' = [cli.r32]

                If the .b32.obj rule is changed to replace $<  by
                $*.b32, pdmake will work correctly.

                Unfortunately, after spending a day and a half on
                this bug, I cannot offer a program correction  to
                fix it,  and  I cannot  spend  more time  on  it.
                Volunteer efforts are welcome.

                The call  sequence  is  such  that  make()  calls
                dyndep() which sets $<  in a call to  setmacro(),
                then make()  calls make1()  which calls  docmd2()
                which calls expand()  which then substitutes  for
                $<.  If a  file in  the dependency  list must  be
                made, make() will call itself recursively  before
                calling make1(), and that call substitutes a  new
                value of $<.   The problem  is that  the code  in
                dyndep() to  set $<  cannot be  used directly  in
                make1() before the docmd2() call, because at that
                point, a rule is not being expanded, and a change
                to $<  would require  knowledge about  the  files
                which does not seem to be available there.

[06-Feb-88]
                Revised lpt.ps to handle formfeed and tabs.

[03-Feb-88]
                Alfred  Ganz  ([e-mail])  has   been
                updating the catdvi  program which converts  Unix
                troff  C/A/T  output  to  a  TeX  DVI  file;  the
                existing version only  knows about  the very  old
                DVI format version  1.  In doing  so, he found  a
                bug in setchar() in  dvialw.c.  DVI files  output
                by TeX normally  will not cause  setchar() to  be
                entered.  There  is a  missing close  parenthesis
                that should have  been output about  line 106  in
                setchar().  Here  is  a Unix  context  difference
                (diff -c) listing; '+' marks the inserted line.

*** dvialw.c,78 Sun Nov  1 11:21:38 1987
--- dvialw.c    Wed Feb  3 16:38:28 1988
***************
*** 1080,1085 ****
--- 1080,1086 ----
                }
                OUT_CHR('(');
                OUT_XCHR(c);
+               OUT_CHR(')');
                if (ycp != str_ycp)
                {
                    OUT_NUM(xcp);


[03-Feb-88]     {Adobe Transcript warning}
                Alfred Ganz ([e-mail]) reports  that
                the Adobe Transcript spooler on his machine  does
                not do page accounting  correctly when the  input
                file  contains  a   Ctl-D  (the  last   character
                produced by dvialw).  That character is there  to
                signal end-of-job  to  the printer;  although  it
                would normally be supplied by a spooler  program,
                dvialw is  used on  many machines  (e.g. IBM  PC)
                with  less  sophisticated   connections  to   the
                printer, and  it  therefore  supplies  the  Ctl-D
                itself.  If you are  using Transcript, check  the
                accounting records it creates, and if  necessary,
                comment out the final line

                    OUT_CHR('\004');    /* PostScript end-of-job signal */

                in devterm() in dvialw.c.  A similar patch should
                be applied to lptops.c; look for the line

                if (putchar('\004') == EOF) /* CTL-D for EOF signal */

                and change it to output a newline ('\n') instead.

[25-Jan-88]
                A couple  of users  have  commented on  the  slow
                speed and large output  file sizes of dvil3p  for
                the DEC  LN03+.   The  contributor,  John  Sauter
                ([e-mail]), clarifies:

                ``Yes, it does  create bitmaps.  If  you have  an
                LN03-PLUS but  no  font  cartridges  DVIL3P  will
                work, whereas  DVI2LN3  (Flavio  Rose's  program)
                requires at least one font RAM cartridge but does
                not require the upgrade to full graphics (LN03 to
                LN03-PLUS).''

                It would  clearly be  desirable to  have  another
                version  that   supported   a   downloaded   font
                mechanism   like   the   Flavio   Rose    driver.
                Volunteers,  anyone?   I  have  no  LN03   access
                locally to do it myself.

[20-Jan-88]     {VAX VMS Warning}
                I have observed that under  VAX VMS, when a  font
                substitution file is used, the drivers may  issue
                the following (spurious) message:

%fontsub():  Bad font substitution at line 3 in file [TEX_INPUTS:texfonts.sub]:
[SYS$INPUT]
Current TeX page counters: [0]

                They then continue  correctly with the  requested
                substitution:

%Substituting font file [amcsc10 [mag 1369]] by [SYS$TEX:[TEX.CM.274]cmcsc10.pk
[mag 1369]]
Current TeX page counters: [0]

                Simply    relinking    the    program    (WITHOUT
                recompilation) with the  debugger and running  it
                again causes  the  message to  disappear.   I  am
                therefore  inclined   to  suspect   a  VMS   code
                generation error; since the message is  harmless,
                I do  not  propose  to  investigate  it  further.
                Since VMS lacks the ability to insert a  debugger
                into the address space at run-time, like  TOPS-20
                can, it  would be  very difficult  to track  down
                this error; the above  output indicates that  the
                current input line read "SYS$INPUT", when in fact
                no such string is found in texfonts.sub.

[13-Jan-88]
                TEXIDX.C needs  some  changes to  work  correctly
                under  VAX  VMS  because  of  flaws  in  the  VMS
                library.  Somehow it got overlooked for  testing.
                Here is a Unix context difference listing of  the
                changes (diff -c old new):

*** texidx.c,13 Sat Nov 14 23:21:38 1987
--- texidx.c    Wed Jan 13 11:51:49 1988
***************
*** 51,56 ****
--- 51,59 ----
  #include <stdio.h>
  #include <ctype.h>

+ #define READ read
+ #define EXIT exit
+
  #ifdef KCC_20
  #include <file.h>
  #define tops20
***************
*** 57,62 ****
--- 60,69 ----
  #else
  #ifdef OS_VAXVMS
  #include <file.h>
+ #undef READ
+ #define READ vms_read
+ #undef EXIT
+ #define EXIT vms_exit
  #else
  #ifdef OS_ATARI
  #else
***************
*** 413,419 ****
      }

    flush_tempfiles (tempcount);
!   exit (0);
  }

  /* This page decodes the command line arguments to set the parameter variables
--- 420,426 ----
      }

    flush_tempfiles (tempcount);
!   EXIT (0);
  }

  /* This page decodes the command line arguments to set the parameter variables
***************
*** 1027,1033 ****

    if (desc < 0)
      fatal ("failure reopening %s", infile);
!   file_size = read (desc, data, total);
    file_data = data;
    data[file_size] = 0;

--- 1034,1040 ----

    if (desc < 0)
      fatal ("failure reopening %s", infile);
!   file_size = READ (desc, data, total);
    file_data = data;
    data[file_size] = 0;

***************
*** 1676,1682 ****
       char *s1, *s2;
  {
    error (s1, s2);
!   exit (1);
  }

  /* Print error message.  `s1' is printf control string, `s2' is arg for it. */
--- 1683,1690 ----
       char *s1, *s2;
  {
    error (s1, s2);
!
!   EXIT (1);
  }

  /* Print error message.  `s1' is printf control string, `s2' is arg for it. */
-------